Довольно распространенная ошибка, позволяющая осуществлять удаленные DoS-атаки на Windows-приложения. Предисловие: Предположим, программа должна прочитать файл с диска, если нет - перейти к обработчику ошибки. Обычный алгоритм, используемый программистами, описанный в учебниках по Паскалю ;) и т.д. выглядит примерно так:
открыть файл
если ошибка то
сообщить "файл не существует"
выход
иначе
длина=0
ИнициализироватьБуфер()
пока Не КонецФайла Выполнять
длина=длина+ПрочитатьФайл(буфер)
КонецЦикла
ОбработатьСодержимое(длина,буфер)
ВывестиРезультат
конец если
Конечно, перед открытием неплохо бы проверить, действительно ли существует
запрашиваемый файл и узнать его длину, но многим это кажется лишним - ведь если
файла нет, первая строка возвратит ошибку, а длину файла можно получить через
функцию чтения, как описано в примере. Кроме того, при реализации проверки на
наличие файла в мультиплатформенных программах возникают дополнительные
сложности.
Однако, во многих OS существуют имена файлов, открытие
которых возможно, однако это вовсе не означает, что из этих файлов можно
безопасно читать. Речь идет о файлах устройств. В Unix-системах это файлы из
каталога /dev, в DOS/Windows - COMx, LPTx, CON, PRN, AUX и т.д. Функция чтения
из такого файла будет ожидать некоторое количество данных, пришедших из порта,
обычно равных размеру буфера. При этом вовсе не факт, что эти данные
когда-нибудь туда попадут.
В IIS4/5 обнаружены две таких ошибки (вместо
com1 нужно подставить имя существующего в системе устройства).
http://host/com1.asp - возвращает пустой ответ, а иногда - требование
NTLM-авторизации (только не спрашивайте, пожалуйста,
почему...)
http://host/com1.idq - говорит error processing file, т.е.
открывает его, и уже потом как-то понимает, что файла-то нет.
К
сожалению, из-за отсутствия под рукой (в локалке) IIS и от глобального нежелания
его ставить, я не определил, приводят ли эти ошибки к зависанию чего-либо или
расходу ресурсов, так что единственно пока найденое применение - определить,
есть ли такой порт на удаленном сервере :)
Если нет, то получается обычная
404 в первом случае и file not found во втором.
Теперь - об уязвимостях,
основанных на данной ошибке.
В основном они касаются Win32, т.к. в Unix
имя файла содержит путь, который создатели скриптов уже привыкли фильтровать.
Кроме того, можно ограничить права доступа к /dev для пользователя, с правами
которого исполняются скрипты. С Windows, где файлы устройств "лежат" в каждом
каталоге, такое не пройдет.
Потенциальной жертвой может быть, например,
серверное приложение, каким-либо образом получающее от пользователя произвольное
имя файла и затем читающее его. Впервые ошибка была обнаружена в Frontpage
Extension 3, при аплоаде файла для отсылки результатов формы через shtml
серверные расширения вышеописанным образом читают файл, указанный в качестве
местоназначения результатов формы, и при указании COMx (какого-либо
существующего порта сервера) "уходят в себя". Ошибка трехлетней давности, так
что подробности не помню.
Более свежий случай - tradecli.dll - 1С:
Аркадия для 7.5 - ошибка 3.
Совсем нехорошо, если такая ошибка
встретится в интерпретируемых серверных скриптах - эксплоит приведет к зависанию
интерпретатора и, соответственно, невозможности выполнения всех скриптов такого
типа. Пример - файл viewasp.asp на www.asp101.com. Символично, что создатели
сервера, призванного научить весь мир программированию на .asp, делают ошибки в
собственных скриптах.
Кроме того, есть возможность "повесить"
интерпретатор хостинга, сознательно сделав "ошибку" в своем скрипте. Например, в
том же .asp открыть COMx через sсripting.FileSystemObject и попытаться
что-нибудь оттуда прочитать. Пожалуй, это пойдет в багтрак для продукта
IIS.
Есть сильное подозрение, что после подвисания в логи IIS не попадает
информация о последнем запросе, ведь в логе должен фигурировать код ошибки,
который вернула подсистема, а такой код, как "зависание", создатели подсистемы
вряд ли предусмотрели :)
Для общего развития, побродив по Яхе, нашел еще
парочку узвимых скриптов. По статистике (сами понимаете, небогатой), уязвимым
оказался каждый третий скрипт, получающий имя файла в качестве
параметра.
Перед открытием файла надо проверять функцией FindFirst, существует ли он.
Для windows-приложений этого достаточно.
